home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970326-19970626
/
000046_news@columbia.edu _Fri Apr 4 07:12:49 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id HAA22722
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 4 Apr 1997 07:12:49 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id HAA21355
for kermit.misc@watsun; Fri, 4 Apr 1997 07:12:48 -0500 (EST)
Path: news.columbia.edu!sol.ctr.columbia.edu!news.msfc.nasa.gov!news.maxwell.syr.edu!news.mathworks.com!uunet!in2.uu.net!204.238.120.21!jump.net!grunt.dejanews.com!not-for-mail
Date: Fri, 04 Apr 1997 02:01:17 -0600
From: e.ingram@uk22p.bull.co.uk
Subject: Re: wanted: Refused Disposition explanation
Newsgroups: comp.protocols.kermit.misc
Message-ID: <860140780.32126@dejanews.com>
Organization: Deja News Usenet Posting Service
References: <859969673.27378@dejanews.com> <5htrl1$gme$1@apakabar.cc.columbia.edu>
X-Article-Creation-Date: Fri Apr 04 07:59:40 1997 GMT
X-Originating-IP-Addr: 137.213.252.252 (beehive-pipex.uk03.bull.co.uk)
X-Http-User-Agent: Mozilla/2.0 (compatible; MSIE 3.01; Windows 3.1)
X-Authenticated-Sender: e.ingram@uk22p.bull.co.uk
Lines: 26
Xref: news.columbia.edu comp.protocols.kermit.misc:6861
In article <5htrl1$gme$1@apakabar.cc.columbia.edu>,
fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:
>
> Normally when you send a file, the disposition (what to do with the file
> when it arrives) is "store it on the disk". However, Kermit can also send
> files with other dispositions, like "print", "send as e-mail", "submit as
> a batch job", etc. If the receiver does not support the indicated
> disposition, or cannot handle the specifics (e.g. an invalid printer name
> was given for a print job), it refuses the file with reason: disposition.
>
In this instance, the default "store it on disk" disposition is in use.
Checks have been made on the target PC and there is no shortage of space
available. The target destination on the PC is *not* the root directory
so there can be no problem with the number of files present in the target
directory.
The connection between the systems is a dial_up line and is generally
reliable.
What circumstances might give rise to this type of transfer failure?
Eric
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet